If you want to use suntar 2.0 only on floppy disks, as you did with previous versions, you need no more informations. But otherwise, you're entering a world which is not well known to normal Macintosh users, and sometimes even to experienced users. Suntar 2.0 may do things at a lower level than Norton or other utilities: e.g. they can show you any sector in a disk partition, but suntar can show you sectors in the partition map, or in a non-Mac partition, or in a disk without a Mac-like partition map.
Obviously you may follow the method which is typical on the Mac: simply launch the application and experiment. But if you are afraid of doing that, or you have problems, I'll try to explain how the Macintosh handles devices.
Devices, drivers and drive numbers
A device, e.g. a hard disk, is not so simple as you may think: at least, there is a number of components and each one changes the rules, that is what must be done to access the device.
The read/write head on the disk gets and requires analog signals, that is electric signals whose value changes with time. The "controller" takes these signals and transforms them into digital signals, i.e. a sequence of binary numbers.
The controller for the floppy disk is connected directly to the Macintosh, but the applications running on it should never access it direcly, for two reasons: one, Apple may change it in future Macs and you want that your old applications will run on them too; two, chip manufacturers adore making controllers very difficult to use: if they may save a cent in the manufactoring cost but in doing so they make the rules so innatural that a programmer must experiment for a few days before beginning to understand what that chip really does and its manual confusely tried to explain, well, you may bet that's the design which goes into production, and in order to avoid every programmer the burden of handling that chip, Apple has introduced a set of rules to write a "device driver".
A "device driver" is similar to an application since it runs on your Macintosh, but it's dissimilar from an application since you never see it: only applications see it and they send to it commands like "read the 1000th sector", which the device driver translates into a series of operations on the controller.
Launch suntar and select the "Drive list" command (in Expert mode): you'll get something like this (obviously without the extra comments):
driver nr. -2 is .Sony (ROM) don't care, it's duplicated here only for
compatibility with the pre-Mac Plus HD20
driver nr. -4 is .Sound (ROM) sends sounds to the speaker
driver nr. -5 is .Sony (ROM) the floppy disk
driver nr. -6 is .AIn (ROM) serial port
driver nr. -7 is .AOut (ROM)
driver nr. -8 is .BIn (ROM) serial port
driver nr. -9 is .BOut (ROM)
driver nr. -33 is .SCSI00 (RAM nonrelocatable) the internal hard disk
driver nr. -49 is .Display_Video_Apple_V8 (ROM) even that requires a driver !
Some drivers know that the device which is accessed through them may contain a "file system" hence they tell to the System software that a number of "volumes" may be mounted through a "drive number" (don't confuse drives and drivers !): the Drive list command tells also about that (you need not be in Expert mode):
drive 1 driver -5 (.Sony) Standard floppy disk drive
SuperDrive (GCR 800k-MFM 720/1440k) not present
drive 8 driver -33 (.SCSI00) ID=0 fixed disk mounted as "HD40"; blocks=81984
Only drives are guaranteed to accept regular read/write commands, hence only device drivers connected to drive numbers may be opened by suntar. Beware: a driver may be connected to many drives and some drivers, just to be sure to have enough drive numbers, create a lot of drives, that does not hurt the user since before a drive is mounted you don't see it, but that means that you may see drives which don't correspond to any physical device and are marked "not present".
When you use suntar to open a drive number, suntar talks to the driver which then talks to the hardware: e.g. when you open drive 1 .Sony, suntar will be able to read and write on the internal floppy disk drive. If you insert a disk when suntar is running but has nothing open it will intercept the event and will check if it's a Macintosh or MS-DOS disk: if it isn't suntar opens the device driver for that drive.
SCSI hard disks and their drivers
The inclusion of a SCSI port on the Mac Plus introduced a new level of complexity: the SCSI protocol is complex enough to require a small computer which converts the commands specified by the SCSI standard to operations on the controller: that small computer is inside the box containing the disk, and that's why an hard disk for the Mac costs more than a hard disk for a PC clone. The job which usually was performed by the device driver on the Mac is performed by the computer inside the disk box, but a device driver is still needed since the Finder and the applications can speak only the language of the device drivers, not the language of SCSI: such languages are very similar but parameters occupy a different number of bits and are placed in different positions. So, the ".SCSI00" device driver performs the translation for my internal disk "HD40".
That seems simple, but Apple made things more complex deciding that the device driver for a SCSI device must reside on the disk itself, in a special partition (hard disks are always partitioned, even when you see only one partition). E.g. here is what suntar tells about my hard disk:
Partition map test
Disk in Apple format block size=512 number of blocks=82080
partition name="Macintosh" type="Apple_Driver" start=64 size=32 (the device driver)
partition name="MacOS" type="Apple_HFS" start=96 size=81984 (the "HD40" volume)
When the Macintosh boots it performs a few "SCSI READ" commands, if it finds a driver then it loads it, and then the system software does not perform any more any SCSI commands, it only sends driver commands to the driver. Probably Apple was afraid of manufacturers which do not follow the SCSI standard: if the SCSI READ command works, at least for small sector numbers, and the manufacturer provides a formatting utility which writes to the disk a device driver which knows how to do anything else, then that disk may be used on any Mac without having to install any additional software. That's how a driver may compress or encrypt the disk without any incompatibility problem.
So, a SCSI device may belong to one of these categories:
a) regular disks: the manufacturer may give you some utilities, but if the drive comes formatted for the Mac it may be immediately connected to your Mac and it's mounted on the desktop when you boot
b) non-disks, e.g. printers, scanners, tape units: obviously they'll never be mounted hence the boot procedure will not find a device driver on them. The device is sold with a floppy disk containing some software (maybe a device driver, but often an application) which allows you to use the device: without that software, the device exists only for utilities which look on the SCSI bus, such as SCSIProbe and suntar
c) removable disks: according to Apple rules they should be recognized and mounted only if a disk is present when the Mac boots. That's foolish, and that's why the manufacturer gives you a floppy disk with some software (a device driver !) to be put in the System folder so that the drive list will be correctly updated anyway. However, if the disk is present the device driver in the disk is loaded first, and remains there when you swap disks: a removable disk may happen to be handled by different device drivers according to what you've done with that drive, and that's exactly what Apple wanted to avoid when it decided to put the driver on the disk itself. See the documentation of SCSIProbe for more informations
d) floppy-disk compatibles (e.g. floptical drives, or 1440k drives for Mac Pluses and old SEs): compatibility forbids to put a partition map and a device driver on a standard floppy disk, otherwise it would not be considered a Mac disk when inserted in the internal floppy drive (the .Sony driver does not handle patitions). At least in one case that was solved without requiring software in the system folder, by storing the partition map and the device driver in nonvolatile silicon memory in the SCSI controller and letting it cheat: the SCSI command "READ sector 0" return sector 0 of this fixed partition map telling that there is a device driver partition and a Mac HFS partition: only requesting a sector in the HFS partition one gets data from the real disk.
Suntar may access SCSI devices directly, by sending standard SCSI comands on the SCSI bus, or it may access them through their device driver, if one exists. However, in most cases the two methods are NOT equivalent, since the device driver lets you access a partition, not the entire disk.
When using suntar to access non-Mac disks in the "normal" cases a) and c), you must open the device as a SCSI ID, since the device driver (if one is loaded) does not see a partition map and issues only error messages or maybe shows a subset of the real disk as the "Mac partition" (some drivers don't read the partition map but use fixed sector numbers); in case d) you should use the device driver, since the "Mac partition" is the real disk. For non-disk devices suntar can't open the device driver, if any exists, hence the SCSI ID is the only possible door: obviously printers and scanners don't recognize "read sector" commands: suntar allows you to try, but that's because a rigid refusal would prevent you from using units that do behave like hard disks but do not declare to be hard disks, e.g. Apple's 40 Megabyte tape unit (now out of production and totally obsolete).
When a device driver or a SCSI device is opened, suntar creates a "Device" menu containing some commands which may be useful: Eject, Mountâ•”: there are three different versions of this menu for device drivers, non-tape SCSI devices, tape devices.
Beware: through the device menu you can directly send some SCSI commands (e.g. stop motor): it's a level of power that I believe no other utility can give you. That's powerful, but it's also dangerous. Some time ago I stopped the motor of my hard disk, then quitted suntar. Well, the Finder can't restart the motor and suntar was inaccessible on the stopped disk, powering off the Macintosh was the only way to exit from that situation, so now suntar forbids a number of operations on the startup disk, but it may still send very destructive commands: writing to the partition map, for example, and I've never tried to see whether Norton can recover that problem, it usually talks to the disk through the device driver, which works only when there is a valid partition map. That's why you must pass two levels of alert dialogs (and a "allow write commands" command) before being able to write.
Tape units
Since the "t" of tar means tape, a tar program which supports SCSI devices should support tape units: however, that part of suntar is at most "beta" software and it will be so for a long time, mainly because
1) tape units can't be found everywhere, and sometimes there are problems with cabling (e.g. Sun units do not use the standard SCSI 50-pin connectors). Hence we've personally tested suntar 2.0 on only a couple of tape units, and that was the beta 4 version (April '93)
2) the SCSI standard specifies three different ways to interpret the parameters of the SCSI READ command, for "hard disks", "fixed blocks tapes" and "variable blocks tapes", and the way to tell which format is in use is not perfectly clear: if the standard is confuse, manufacturers don't follow it faithfully and the situation is somewhat chaotic
3) the SCSI committee defined a standard set of commands which should allow one to control devices from different manufacturers without writing specific code (i.e. device driver) for each one: however, this feature has had a very low priority: most commands and features are optional, and it's not guaranteed to be able to know which ones are supported and which ones are not: for a while almost all manufacturers included a list of supported commands (but not of supported parameters) in the "vendor specific" informations returned by the SCSI inquiry command, but older devices didn't do that, and unfortunately SCSI-2 did not make that list official, hence manufacturers are now deleting that information in new versions of SCSI controllers that once had them.
Currently suntar 2.0 was tested on these tape units:
a) Apple SC40 tape unit (a very old unit, manufactured by 3M): really, from the software point of view it should be considered a hard disk, since the supported variant of the READ command is the "hard disk" one: obviously as hard disk it's extremely slow. I could not know whether a "vendor specific" command sends it into the "fixed block tape" mode, hence testing it was useless (well, not really: we learnt that it's important to defend ourselves against devices which lock the SCSI bus and that powering off and then on the Mac is not the only way to exit from such a situation: now suntar succeeds to exit from that gracefully, usually without resetting the whole SCSI bus and hence all your peripherals.)
b) a quarter-inch tape labeled Sun (manufactured by ARCHIVE): it's a fixed block unit and the tests were successful
c) an Exabyte unit, which works in the "variable blocks" mode: some tests were successful, others failed but in one case the beta-tester had forgotten to rewind the tape before reading, in another case the SCSI chain was not terminated (no available terminator with the proper connector) and the tape seemed defective, hence currently I can't know whether suntar may handle an Exabyte reliably or not
d) a 4mm DAT manufactured by WangDAT: this unit has its own way to interpret the
variable blocks mode: the beta tester allowed us to identify the problem but he did not test the modified version which should have fixed the problem
5) a DAT unit manufactured by ARCHIVE: tests were successful.
Some suggestions:
1) Since the UNIX tar allows to place more archives on a single tape, rewinding the tape in order to "go to sector 0" might really place the tape far from your data. Hence suntar avoids to automatically rewind the tape, and you must often use the explicit rewind comand in the Device menu. "Skip file" commands are good for multiarchive tapes, however "skip file backwards" leaves the tape positioned before the end of file marker, hence it must be followed by a skip file forward before starting reading from that position, unless it didn't find any marker and reached the beginning of medium.
2) suntar was born for floppy disks and its default buffer size (9k) is good for floppy disks but is small for tapes. In order to increase it, simply allocate more memory to suntar (unless you're still using System 6 wih Finder, then the allocated memory is already the maximum one)
3) you may edit the option "supported tape operation" (rarely used options, available only in expert mode) containing a comma or space-separated list of operations which the tape certainly supports and/or "unsupported tape operation" with operations not supported. The coding is:
0 skip file forward
1 skip file backwards (both may be tested from the Device
menu, but beware: the SCSI-1 standard specifies a single error code
for these causes: command not supported, wrong parameters to the
command, the current status of the unit is not compatible with
executing the command (e.g. missing tape, or tape at end of medium):
so a failure does not mean that the command is not supported, unless
the unit supports the new SCSI-2 error codes (additional sense key).
If the list of supported commands is supported, note that 0,1,2,3 are
all implemented by command 11 of group 0, but it need not implement all
four operations
2 skip block forward ("fast forward" movement, may be tested with a
List of an archive containing long files, e.g. 100k or more)
3 skip block backwards (may be tested by an "Append" command)
4 may use multiple fixed blocks reads and writes
5 standard SCSI variable-blocks read where the block size is
determined only after reading it into main memory (not supported
by the WangDAT, which uses a non-standard way to determine the
size before performing a READ, which otherwise fails)
6 standard "request sense" with a nonzero buffer size
7 write filemark (command 10 of group 0, may be tested from the Device menu)
8 the archiving software uses fixed-sized blocks even if the tape unit supports variable-sized blocks (that's true for all versions of UNIX tar)
If a bit is missing in both resources suntar uses the default, if it's 1 in both usually the "unsupported" wins.
If such resources are missing suntar tries to guess, and that may cause slower operations (e.g. not using "fast forward" to skip long files when listing the archive) or may not work.
Obviously future versions will have an internal database for a number of known tape units, but currently we haven't the full informations for any of the tested units.
Understand, this is freeware, while e.g. DOS-tar costs more than 300$ in the version which supports tapes. The people who have the know-how to write a reliable Mac-tar (the makers of DOS-tar or of Retrospect) haven't yet seen the opportunity so by now there is no other choice. The price which is asked to you is to help us test it, or to make the "tested units" list longer, and create the "supported operations" strings: if you try suntar successfully with a tape unit, you should send me (at the E-mail address which you may find in the about box of suntar or in the "read me" file) a description of which operations were performed successfully and a copy of the informations printed by suntar when it opens the device (better if in "expert mode", suntar becomes more verbose in such a case): that is, something like this:
Device type: Tape unit
Device type qualifier: 0
Removable: yes
ANSI version: 1
VendorID: EXABYTE
ProductID: EXB-8200
Revision: 425A
The list of supported commands is not available
MODE SENSE test
medium type 133
write protected: no
density code 0 blocks 2294048 block size 0
READ BLOCK LIMITS test
reserved byte=0
minimum block size=1 maximum=245760
And if you have problems, well, suntar 2.0 has a "debug mode" which prints a lot of informations about what it's doing and about error messages from the SCSI device, activated by option-open device and assigning a "verbosity level": maybe those informations will allow us to fix the problem.
